Sharing network resources with user groups, divisions or any other companies in software defined networking (SDN) is gaining increasing attention recently owing to its promises for better network utilization. Resource sharing is effectively realized in SDN by empowering these parties at the control plane with permissions for administrating network components or parts thereof. Different tenants can lease a network slice (and therefore share the network resources) by installing and running their own application atop the network owner's controller using a so-called north-bound application programming interface (API). These different tenants usually share network resources and at the same time might also compete among each other.
Restricting the access of the network users (i.e., the network owner and the leasing tenants) and the applications to the network components emerges as a necessity to ensure the correct operation of the SDN network. Conventional methods and systems (for example as shown in the non-patent literature of R. Sherwood, G. Gibb, K.-K. Yap, G. Appenzeller, M. Casado, N. McKeown, and G. Parulkar, “Can the production network be the testbed?”, in Symposium on Operating Systems Design and Implementation (OSDI), 2010; P. Porras, S. Shin, V. Yegneswaran, M. Fong, M. Tyson, and G. Du, “A security enforcement kernel for OpenFlow networks”, in Workshop on Hot Topics in Software Defined Networks (HotSDN), 2012; and F. Klaedtke, G. Karame, R. Bifulco, and H. Cui, “Access control for SDN controllers”, in Workshop on Hot Topics in Software Defined Networks (HotSDN), 2014) rely on a reference monitor to orchestrate access to the network by the various tenants and to resolve possible conflicts among them.
However, these conventional methods and system require that a central reference monitor learns all the rules installed by all the tenants. The reference monitor should have global knowledge about the rules installed in the SDN in order to make correct access control decisions. However this results in a loss of privacy of the SDN tenants. This is especially evident when the reference monitor implementation is outsourced, e.g., to another executing environment that is not necessarily trusted by tenants. For instance, the reference monitor can be outsourced by one SDN domain to execute by another tenant that administrates some or all of the switches, e.g., in a federated SDN network. Alternatively, the reference monitor could be outsourced to a public cloud server, since service providers providing a reference monitor have considerable incentives to rely on hosted services in the cloud, since this enables them to maximize the availability of the service while minimizing the costs for acquisition of hardware and operation. Indeed, the cloud offers a low barrier for small and medium enterprises to offer services and enables its clients to avoid huge upfront investments to accommodate for peak usage. However, outsourcing a reference monitor raises serious privacy concerns with respect to the leakage of tenant information to the cloud provider or other tenants.